Method of detecting malicious code

ABSTRACT

The invention provides a method of detecting malicious code in a code-executing device ( 10 ), the method characterised in that it includes the steps of: (a) generating test data which is substantially unsusceptible to compression without reducing its information content and storing it as image data ( 230 ) in memory external to the device ( 10 ); (b) loading the test data (R 0  to R m ) into memory ( 30 ) of the device ( 10 ); (c) performing a checksum calculation on the test data (R 0  to R m ) stored in the memory ( 30 ) of the device ( 10 ) to generate a first checksum value, performing a corresponding checksum calculation on the image data ( 230 ) to generate a second checksum value, and the comparing the first value with the second value to determine whether or not the test data in the memory of the device ( 30 ) has been corrupted; (d) repeating step (c) until sufficient test data in the memory ( 30 ) of the device ( 10 ) is checksum tested to determine whether or not malicious code is present in the device ( 10 ). The method makes it difficult for the malicious code to conceal itself from the checksums, hence it is possible to determine whether or not the device ( 10 ) has been compromised.

[0001] The present invention is concerned with a method of detectingmalicious code in a code-executing device, in particular but notexclusively in a computer. The invention also relates to a testapparatus operating according to the method.

[0002] Malicious code, for example computer viruses, frequently causessevere problems in contemporary code-executing systems. Such maliciouscode can remain dormant after initially being loaded and then, whenactivated, potentially result in extensive damage to the integrity ofdata and executable software stored in the systems.

[0003] There are presently available a number of techniques forverifying the authenticity of executable code, for example by encryptingthe executable code and then decrypting it before use, and by the use ofauthentication signatures using private or public key cryptography.These techniques are employed to prevent unauthorised executable codebeing loaded into systems and executed therein. However, if anencryption code or a private key is stolen from its legitimate owner andcomes into the possession of a third party, the third party can generatemalicious code which will verify correctly against decryption codes andcorresponding public keys.

[0004] The inventors have appreciated that malicious code gives rise tofirst and second problems. The first problem is concerned withcountermeasures to prevent malicious code being loaded intocode-executing systems. The second problem is concerned with determiningwhether or not a code-executing device loaded with executable code hasbeen compromised where doubt exists regarding the authenticity of thecode. For example, in a scenario where it is suspected that maliciouscode has been loaded into a code-executing system, proceeding to executethe code could wreak costly damage to valuable databases accessible fromthe code-executing system. Conversely, resetting and subsequentlyreprogramming the code-executing system could itself be a costlyexercise entailing the return of the system to its manufacturer.Moreover, in many circumstances, it will be essential to know whether ornot an attempt has been made to distribute malicious code which haspassed authentication procedures such as public keys so that otherprotection measures can be pursued, for example purging devices ofmalicious code.

[0005] The inventors have also appreciated that malicious code can oftenbe constructed in cunning ways to occupy very little memory space incode-executing devices and only use significant internal device memory,or external memory accessible from the device, when the malicious codeis active. Trying to detect such malicious code can be very difficultespecially when it becomes embedded in seemingly bona fide executablecode which, for a majority of the time, appears to be functioningcorrectly.

[0006] Thus, the invention sets out to provide a method of detectingwhen malicious code has been loaded into code-executing devices.

[0007] According to a first aspect of the present invention, there isprovided a method of detecting malicious code in a code-executingdevice, the method characterised in that it includes the steps of:

[0008] (a) generating test data which is substantially unsusceptible tocompression without reducing its information content and storing it asimage data in memory external to the device;

[0009] (b) loading the test data into memory of the device;

[0010] (c) performing a checksum calculation on the test data stored inthe memory of the device to generate a first checksum value, performinga corresponding checksum calculation on the image data to generate asecond checksum value, and then comparing the first value with thesecond value to determine whether or not the test data in the memory ofthe device has been corrupted;

[0011] (d) repeating step (c) until sufficient test data in the memoryof the device is checksum tested to determine whether or not maliciouscode is present in the device.

[0012] The method provides the advantage that calculating checksumvalues for the test data in the memory of the device and comparing withcorresponding checksum values calculated for the image data enablesmalicious code residing in the memory of the device to be detected.

[0013] Insusceptibility of the test data to compression prevents anymalicious code residing in the memory of the device from concealing itsexistence by compressing the test data. It is especially preferable thatthe test data includes one or more random number sequences; randomnumber sequences are by their nature not capable of being compressedwithout loss of associated information.

[0014] Conveniently, the method additionally includes a step ofinterrogating the device to make it divulge names of softwareapplications stored therein prior to performing step (b) to overwritethe applications in the memory of the device.

[0015] When the method has been applied to establish that the device isdevoid of malicious code, it is preferable that uncorrupted versions ofthe software applications divulged by the device are loaded into thedevice after step (d). Such loading of uncorrupted software enables thedevice to be returned to its former state prior to applying the method.

[0016] In order to make it more difficult for any malicious coderesiding in the device to predict checksum values required whenexecuting the method, it is beneficial that checksum calculationsperformed in step (c) are performed on one or more sequences of memorylocations of the memory of the device in response to challenges issuedto the device, each challenge specifying memory locations of the deviceto be checksummed using a cryptographic checksum calculation and alsoone or more associated initialization vectors with which to commence thecalculation. Because the malicious code cannot predict the memorylocations chosen or the initialization vector used in the method, it ismore difficult for the malicious code to pre-compute checksum values andthen compress the test data to conceal its presence.

[0017] Advantageously, to make it more difficult for the malicious codeto conceal itself, the aforementioned one or more sequences may skipmemory locations therein. Such location skipping provide the benefitthat the memory of the device can be tested in several different ways,thereby making it more difficult for the malicious code to concealitself.

[0018] It is preferable that at least one checksum calculation in step(c) is performed on interfacing software residing in the memory of thedevice, the interfacing software operable to communicate the test datato the memory of the device and to output data from the memory of thedevice, the interfacing software also being included in the image datafor comparison. Such testing of the interfacing software assists toreduce a risk of malicious code residing therein.

[0019] Beneficially, the method makes use of the rapidity with which thedevice outputs checksum calculations to determine whether or not thememory of the device includes malicious code. If malicious code ispresent, more processing steps will often be required for the code toconceal its identity from checksum calculations.

[0020] Preferably, when testing the device according to the method, thedevice should be hindered from accessing memory external thereto duringcalculation of the checksums in step (c). If the device is capable ofcommunicating with such external memory, it is possible for maliciouscode to conceal its identity by residing in such external memory or,alternatively, to store test data in the external memory to conceal thecode's presence within the device.

[0021] In step (c), it is preferable that a cryptographic hash algorithmis used for calculating the checksums. Checksums generated bycryptographic hash algorithms are difficult to mimic and hence the useof such algorithms makes it more difficult for malicious code to hideits presence within the device. Examples of suitable cryptographic hashalgorithms are:

[0022] (a) “MD5” defined in an Internet Engineering Task Force (IETF)document RFC 1321, “The MD5 Message-Digest Algorithm” (1992); and

[0023] (b) “SHA-1” defined in National Institute of Standards andTechnology (NIST) documents “FIPS Publication 180: Secure Hash Standard(SHS)”, (1993) and also in “Announcement of Weakness in the Secure HashStandard” (1994).

[0024] In a second aspect of the invention, there is provided a testingapparatus operable to apply a method according to the first aspect ofthe invention to interrogate a code-executing device to determinewhether or not the device includes malicious code.

[0025] Embodiments of the invention will now be described, by way ofexample only, with reference to the following diagrams in which:

[0026]FIG. 1 is a schematic diagram of hardware of a portablecode-executing device;

[0027]FIG. 2 is an illustration of software applications and a handlerloaded into memory of the device in FIG. 1;

[0028]FIG. 3 is an illustration of the device shown in FIGS. 1 and 2connected to a testing apparatus according to the invention; and

[0029]FIG. 4 is a diagram in which is shown steps of a method ofdetecting when malicious code has been loaded into the device in FIGS. 1to 3.

[0030] Referring now to FIG. 1, there is shown hardware of acode-executing device indicated by 10. The device 10 includes anenclosure 20, a main memory 30, a code-executing processor 40 and anassociated random access memory (RAM) 50. The RAM 50, the processor 40and the main memory 30 are electrically or optically interconnected suchthat the processor 40 can access and store data in the RAM 50 and themain memory 30. The device 10 further includes an electrical or opticalinterface 60 for communicating to a network 70 external to the device10. The network 70 can, for example, be a testing device or,alternatively, be a network of interconnected computing devices.

[0031] When the device 10 is a portable code-executing device, the RAM50 typically includes 256 bytes of data storage capacity. Moreover, themain memory 30 is typically implemented in the form of an E²PROMnon-volatile memory including 8 Mbytes of data storage capacity.Furthermore, the processor 40 is typically implemented as an 8-bit or16-bit microcontroller including a bidirectional buffer port providingthe interface 60.

[0032] The device 10 can also, alternatively, be a large computer wherethe processor 40 comprises an array of interconnected digitalprocessors, the RAM 50 comprises many Gbytes of solid state data storagecapacity, and the main memory 30 includes optical, magnetic and solidstate data storage media of many Gbytes storage capacity.

[0033] In operation, the external network 70 communicates to the device10 through the interface 60. When the network 70 sends executable-codeto the device 10, the device 10 stores the code in the main memory 30.Additionally, the processor 40 can be instructed to store specific itemsof data or output specific items of data from its main memory 30, withor without processing applied thereto depending upon circumstances. Themain memory 30 is operable to retain data stored therein, for exampleeven in the event of power to the device 10 being removed.

[0034] The manner in which the device 10 is configured with regard toexecutable code, namely software, will now be described with referenceto FIGS. 1 and 2. Executable code, namely applications 1 to n where n isa positive integer not including zero, is stored in the main memory 30and loaded into the device 10 through the interface 60 which operatesunder software control of an executable-code object 100 known as ahandler. The handler 100 handles all flow of data and executable codebetween the network 70 and the main memory 30 and RAM 50.

[0035] When the device 10 is operating in conjunction with the network70, the network 70 can access the main memory 30 via the handler 100.Alternatively, the network 70 can instruct the handler 100 to startexecution of one or more of the applications on the processor 40, thehandler 100 executing concurrently with the one or more executingapplications for handling data flow to and from the device 10.

[0036] It is thus only possible for the network 70 to communicate to andfrom the device 10 via the handler 100 in normal circumstances.

[0037] Prior to loading an application into the device 10, theapplication is signed by its supplying party using the party's privatekey to ensure its authenticity. The network 70, and also if necessarythe handler 100, is then operable to verify the application using apublic key corresponding to the private key. Such a procedure ofauthentication reduces a risk of the device 10 loading into its mainmemory 30 unauthorised rogue applications.

[0038] The use of private and corresponding public key pairs forauthenticating software is well known, the keys being in the from ofcodes. The codes are such that one code of the pair cannot reasonably begenerated merely from knowledge of the other code of the pair. When asupplying party supplies a software application to the network 70 forrecording into the device 10, the supplying party “signs” theapplication using one of its keys, the supplying party retaining thiskey secret as its “private key” which it does not divulge to the network70. However, the supplying party divulges the other of its keys of thepair to the network 70 and therefrom to the device 10, this being knownas the supplying party's “public key”. Thus, the public key provided bythe supplying party can be used by the network 70 and the device 10 forverifying authenticity of applications signed using the private keybelonging to the supplying party.

[0039] Generation of private and public keys is known from a U.S. Pat.No. 4,200,770 which is hereby incorporated by reference with regard tothe generation of complementary keys. The private and public keys areusually of about 200 bytes in length and can be generated using amathematical transformation described in the U.S. patent.

[0040] Conventional “signing” of software applications using privatekeys will now be described in further detail.

[0041] In a first approach, “signing” involves encoding a softwareapplication in its entirety using a private key to generate acorresponding encoded application. The encoded application can bedecoded using a corresponding public key to the private key. Otherunrelated public keys will not be able to successfully decode theencoded software application to generate viable executable code for usein the device 10. If the handler 100 discovers such non-viableexecutable code when performing decoding, the handler 100 therebydetermines that the executable code is not authentic and should not beexecuted or retained in the main memory 30.

[0042] In a second approach, “signing” involves calculating acryptographic checksum for a software application using a checksumgeneration program known to both the supplying party and to the network70 and the device 10; known cryptographic checksum generating programsinclude “Message Digest 5” (MD5) and “Secure Hash Algorithm” (SHA orSHA-1). The checksum is relatively short, usually in a range of 16 to 20bytes in length. The supplying party can use its private key forencoding a checksum generated using a public checksum generation programfor its software application and then supply the software applicationunencoded together with the encoded checksum, sometimes referred to as aMessage Authentication Code (MAC), to the network 70 and therefrom tothe device 10. When the network 70 receives the software applicationfrom the supplying party, the network 70, and likewise the device 10,can apply the public checksum generation program to generate an operatorchecksum for the unencoded software application. The network 70 and thedevice 10 can then decode the encoded checksum provided by the supplyingparty using the supplying party's public key to generate a decodedchecksum which the network 70 and the device 10 then compare with theiroperator checksum. If the decoded checksum is identical to the operatorchecksum, the network 70 and the device 10 will thereby have determinedthat the software application is authentic. If the decoded checksum andthe operator checksum are not identical, the network 70 and the device10 will have identified that the software application is suspect.

[0043] The second approach to “signing” software applications is fasterand involves less computation than the first approach because checksumgeneration is a computationally quick operation to perform and encodinga checksum of 16 to 20 bytes is easier than encoding software and datain its entirety which can be, for example, several tens of Megabytes insize.

[0044] When the term “signing” is used by the inventors to describetheir invention, this is intended to refer to either signing by thefirst approach or signing according to the second approach as describedabove.

[0045] A problem can arise where a private key of a software applicationsupplying party to the network 70, and therefrom to the device 10, isstolen by a third party. The third party is then able to preparemalicious code and sign it using the private key and supply themalicious code as a software application to the network 70. Neither thenetwork 70 nor the device 10 when checking the application forauthenticity using their corresponding public key will be able to detectthe malicious code.

[0046] If it subsequently becomes known that the private key has beenstolen, software applications signed by the private key then becomesuspect as being malicious code. There then arises a problem of how totest the device 10 to determine whether or not its one or more softwareapplications stored in its main memory 30 include malicious code.

[0047] When malicious code is loaded via the interface 60 and processor40 into the device, the code can be stored in a number of ways, namely:

[0048] (a) the malicious code can overwrite the handler 100, or co-existtherewith in the main memory 30, and function as a rogue handlermimicking the operation of the handler 100 but also performing functionsto the benefit of the third party, for example transferring money from abank account of a legitimate owner of the device 10 into a bank accountheld by the third party;

[0049] (b) the malicious code can be stored as a software applicationand invocable from the network 70 by way of the handler 100, thesoftware application operable to perform an unauthorised function to thedetriment of the owner of the device 10; and

[0050] (c) the malicious code can be stored as data which is operatedupon by bona fide applications and the handler 100 stored in the mainmemory 30, the data resulting in an unauthorised function beingperformed.

[0051] When the handler 100 is replaced by a malicious handler, themalicious handler is capable of concealing the presence of one or morethird party malicious applications stored in the memory 30 wheninterrogated through the interface 60 from the network 70. In such asituation, the device 10 will appear to be functioning correctly fromthe viewpoint of the network 70. Continued use of the device 10 couldresult, for example, in expensive corruption of the network 70 and itsassociated databases. There is therefore a need for a method ofdetecting when suspect malicious code has been loaded into the device10, especially when private-public key authorisation procedures havebeen circumvented by the theft of private keys.

[0052] A method according to the invention of detecting when maliciouscode has been loaded into the device 10 will now be described withreference to FIGS. 3 and 4. In FIG. 3, the device 10 is shown in aconfiguration connected through the interface 60 to a testing apparatus200. In the configuration, the device 10 is deliberately arranged sothat it is only capable of communicating with the apparatus 200. Such arestricted communication is used to prevent malicious code present itthe device 10 from communicating with other devices or using memoryexternal to the device for concealing itself from the apparatus 200.

[0053] In STEP A of the method, the device 10 including its handler 100and its one or more software applications are connected to the apparatus200. The apparatus 200 then communicates through the interface 60 to thehandler 100 and requests it to divulge a list 210 of applications storedwithin it. In some circumstances, the network 70 will itself keep arecord of applications that have been loaded into the device 10;however, such a record is not essential for performing the method of theinvention. The handler 100 thus responds to the apparatus 200 bycommunicating the list 210 of the applications stored in the device 10.

[0054] If the handler 100 has been corrupted to become a malicioushandler, it could lie to the apparatus 200 and conceal the presence ofone or more rogue applications stored in the device 10 as well as bonafide applications.

[0055] When the apparatus 200 has received the list 210 from the handler100, the apparatus 200 stores the list 210 in its own memory.

[0056] In STEP B of the method, the apparatus 200 transmits through theinterface 60 a software application known as a testing handler 220 tothe device 10 which stores it in specific locations of its main memory30. At this stage, the device 10 should only include its handler 100,the testing handler 220 and any applications that the device hasdeclared in the list 210 to the apparatus 200. If the device 10 has beencompromised by malicious code, it may include applications not declaredin the list 210 to the apparatus 200 and the handler 100 itself maycomprise malicious code.

[0057] If the network 70 has its own list of applications that should bestored in the device 10 and this network 70 list is not in conformitywith the list 210, the apparatus 200 will thereby determine therefromthat the device 10 has been compromised by inclusion of presumedmalicious additional code.

[0058] The apparatus 200 then proceeds to instruct the device 10 to runthe testing handler 220. Moreover, the apparatus 200 will know inadvance which main memory 30 locations the handler 100 and the testinghandler 220 should occupy. Memory 30 locations not occupied by thesehandlers 100, 220 should therefore be available for storing softwareapplications.

[0059] The apparatus 200 then generates a reference image 230 within itsmemory of how the main memory 30 of the device 10 should appear.Following the generation of the reference image 230, the apparatus 200generates a sequence of random numbers R₀ to R_(m) and fills locationsof the reference image 230 not occupied by the handlers 100, 220 withthe random numbers. The apparatus 200 also passes these random numbersthrough the interface 60 to the testing handler instructing it to storethe random numbers in locations in the main memory 30 corresponding tothose of the reference image 230.

[0060] Random numbers have the characteristic that they cannot becompressed without losing information content. Thus, if rogueapplications are stored in the main memory 30 of the device 10, and thehandler 100 is a malicious handler, the malicious handler cannotcompress the random numbers to conceal the presence of rogueapplications because, as will be described later, such attempts atcompressing the random numbers can be detected by the apparatus 200.

[0061] The apparatus 200 continues to supply the random numbers to thedevice 10 via the testing handler 210 until all locations of the mainmemory 30 are filled except for those locations occupied by the handlers100, 220.

[0062] In STEP C of the method, the apparatus 200 uses a procedureinvolving initialization vectors (IV) to interrogate the device 10 totest whether or not the random numbers R₀ to R_(m) have been correctlyrecorded in the main memory 30. If incorrect recording of the numbers isidentified, such incorrect recording is indicative of the action of arogue application or that the handler 100 has been compromised.

[0063] When interrogating the device 10, the apparatus 200 sends achallenge via the interface 60 to the testing handler 220. The challengespecifies a sequence of start locations within the main memory 30 and aninitialisation vector (IV). The testing handler 220 then initializes itscryptographic hash algorithm with the supplied IV before feeding thecontents of the sequence of specified locations in turn to thisalgorithm. The algorithm of the testing handler 220 calculates aresulting first checksum which is typically in the order of 128 or 160bits in length. The testing handler 220 then, using an identical IV andan identical cryptographic hash algorithm to that supplied to thetesting handler 220, calculates a corresponding second checksum based ondata stored in the reference image 230. If the first and secondchecksums are not identical, the apparatus 200 determines thereby thatthe device 10 has been compromised. Conversely, if the first and secondchecksums are identical, the apparatus 200 interrogates the device 10using other challenges. If necessary, the apparatus 200 can interrogatethe whole of the main memory 30 include locations occupied by one ormore of the handler 100 and the testing handler 220. If the handler 100has been compromised to be a malicious handler, the apparatus 200 willbe able to detect such a compromise.

[0064] The apparatus 200 preferably interrogates the device 10 usingnumerous different initialization vectors and, if necessary, alsospecifies sequences of varying lengths for use in calculating associatedchecksums. Such multiple interrogation is effective to prevent amalicious handler in the device attempting to pre-compute checksums andthen compress the random numbers as they are supplied to the device 10in order to try to conceal the presence of rogue applications.

[0065] The sequences preferably include locations occupied by at leastone the handler 100 and the testing handler 220. Moreover, the sequencescan optionally alternately skip one or more locations to make it moredifficult for malicious code to conceal itself within the device 10.Such skipping is illustrated by Sequences 1 and 3 in FIG. 4. Sequence 2in FIG. 4 corresponds to consecutive memory locations in the main memory30. Sequence 3 includes locations occupied by the handlers 100, 220.

[0066] If, after interrogating the device 10 with numerous mutuallydifferent initialization vectors, it is determined that the device 10has not been compromised, the method proceeds to STEP D. If the device10 has been compromised, an alarm is raised.

[0067] In STEP D of the method, the apparatus 200 optionally overwritesthe testing handler 220 stored in the device 10 to prevent theexecutable code of this handler 220 being subsequently disclosed to anapplication subsequently executing on the device 10, and then proceedsto load bona fide approved versions of applications as recorded in thelist 210. Such loading results in the device 10 including anuncompromised version of the handler 100, one or more bona fideapplications with remaining locations in the main memory 30 being filledwith random numbers. The apparatus can, if required, optionally purgethe memory 30 of random numbers prior to loading the one or more bonafide applications.

[0068] The method provides the benefit that the presence of maliciouscode within the device 10 can be detected even if applications signed bya stolen private key corresponding to a public key stored in the device10 have been loaded into the device 10. Moreover, the method alsoenables bona fide uncompromised applications to be reloaded into thedevice 10 at termination of the method thereby rendering the device 10again useable.

[0069] The method of the invention will not be able to detect allpossible malicious code. For example, where malicious code is capable ofoperating upon the handler 100 in uncompromised form, compressing it andthen storing the compressed handler and the malicious code in memoryspace originally occupied by the uncompressed handler 100, the methodcan be circumvented. However, the malicious code would have to becapable of interfacing with the testing handler to provide it withsequences of location values normally occupied by the uncompressedhandler 100 when tested during Step C of the method. The testingapparatus 200 could, if necessary, be made sensitive to such compressionby timing interrogation response from the device 10; uncompressing codewill take more time hence malicious code operating in such a manner canbe detected by virtue of its slower than normal response.

[0070] It will be appreciated as described above that the device 10 cantake many different forms. The aforementioned method of the invention isapplicable to both where the device 10 is a portable personal item aswell as where it is a complex computer installation.

[0071] It will also be appreciated to those skilled in the art thatmodifications can be made to the method of the invention withoutdeparting from the scope of the invention. For example, in Step B, themain memory 30 of the device 10 can be filled with alternative dataother than random numbers provided that the alternative data is notsusceptible to being undetectably compressed by any malicious code thatmay be present in the device 10; compression of the alternative datawould potentially provide the malicious code with memory space tocontinue its existence. Moreover, in Step C, the sequences of locationsread for generating the checksums need not necessarily map out the mainmemory 30 in its entirety if a less thorough interrogation of the device10 is acceptable. Furthermore, although use of a cryptographic hashalgorithm for generating the checksums in Step C is described, otherapproaches for generating checksums can alternatively be used incombination with or in substitution for the cryptographic hashalgorithm.

[0072] Although loading of the testing handler 220 into the device 10 isdescribed, it is feasible for the handler 100 itself to be adapted so asto be capable of loading random numbers supplied from the testing device200 into the main memory 30 in Step B, thereby circumventing a need forthe testing handler 220 to be loaded into the device 10.

1. A method of detecting malicious code in a code-executing device, themethod characterised in that it includes the steps of: (a) generatingtest data which is substantially unsusceptible to compression withoutreducing its information content and storing the test data as image datain memory external to the device; (b) loading the test data into memoryof the device; (c) performing a checksum calculation on the test datastored in the memory of the device to generate a first checksum value,performing a corresponding checksum calculation on the image data togenerate a second checksum value, and then comparing the first valuewith the second value to determine whether or not the test data in thememory of the device has been corrupted; (d) repeating step (c) untilsufficient test data in the memory of the device is checksum tested todetermine whether or not malicious code is present in the device.
 2. Amethod according to claim 1 wherein the device is interrogated to makeit divulge names of software applications stored therein prior toperforming step (b) to overwrite the applications in the memory of thedevice.
 3. A method according to claim 2 wherein uncorrupted versions ofthe software applications divulged by the device are loaded into thedevice after step (d) when the device is found to be devoid of maliciouscode.
 4. A method according to claim 1, 2 or 3 wherein the test dataincludes one or more random number sequences.
 5. A method according toany preceding claim wherein checksum calculations performed in step (c)are performed on one or more sequences of memory locations of the memoryof the device using challenges to specify the memory locations and tospecify one or more initialization vectors to be used in the checksumcalculations.
 6. A method according to claim 5 wherein the one or moresequences skip memory locations therein.
 7. A method according to anypreceding claim wherein at least one checksum calculation in step (c) isperformed on interfacing software residing in the memory of the device,the interfacing software operable to communicate the test data to thememory of the device and to output data from the memory of the device,the interfacing software also being included in the image data forcomparison.
 8. A method according to any preceding claim wherein therapidity with which the device outputs checksum calculations is used todetermine whether or not the memory of the device includes maliciouscode.
 9. A method according to any preceding claim wherein the device ishindered from accessing memory external thereto during calculation ofthe checksums in step (c).
 10. A method according to any preceding claimwherein a cryptographic hash algorithm is used for calculating thechecksums.
 11. A testing apparatus operable to apply a method accordingto any preceding claim to interrogate a code-executing device todetermine whether or not the device includes malicious code.